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REMARKS 

This Preliminary Amendment is presented to correct typographical errors in the 
specification and drawings and to clearly and distinctly claim the invention. No new matter is 
added. Entry is respectfully requested. 

The Examiner is respectfully requested to contact the undersigned by telephone if it is 
believed that such contact would further the examination of the present application. 

To the extent necessary, a petition for an extension of time under 37 C.F.R. § 1.136 is 
hereby made. Please charge any fee shortages or credit any overages Deposit Account 
No. 50-1302. 
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MARKED-UP VERSION OF SPECIFICATION PARAGRAPHS 

For purposes of showing the changes from the current version of the application, deleted 
text is shown in [brackets] and added text is underlined . 

Paragraph on page 8, lines 5-10 

The SpendCap Manager™ module 200 is preferably implemented as a web-based 
application server [200] that runs as an extension or module of a web server 203. The web 
server 203 can be any commercially or publicly available HTTP server [203] that implements 
server extensions [APIs] application programming interfaces (APIs) . Access to the SpendCap 
Manager™ module 200 is done via a [URL] uniform resource locator (URL) with special 
keyword that the web server 203 intercepts and redirects to the SpendCap Manager™ module 
200 for processing. 

Paragraph on page 8, lines 11-17 

A user 201 may access the SpendCap Manager™ module 200 via a local server or 
independent service provider server 202 that is connected to the Internet 204. Alternately, the 
user 201 may connect directly or indirectly to the Internet 204 with a suitable browser [201]. 
The web server 203 associated with the SpendCap Manager™ module 200 is also coupled to 
the Internet 204. The user 201 establishes a connection to the web server 203 via the Internet 
204 in order to log onto the system. The log on procedure is illustrated in further detail in the 
flow chart diagram of Figure 3. 

Paragraph on page 8, lines 18-25 

A user 201 logs onto the system in step 205 shown in Figure 3. If the user 201 inputs 
the required password or other authentication information in step 206, he or she is given access 
to the system [200] to create a department object in step 207. A department object is created in 
step 207 for the department 109 in which the user 201 belongs if it has not already been 
created. A department object contains its assigned spending capacity and expenses of the 
department 109 of the user 201 organized in multiple plan objects. A plan object represents a 
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category of spending (called spend accounts 406) of the department 109, such as headcount, 
salary, travel expenses, and miscellaneous spending. 

Paragraph on page 9, line 29 - page 10, line 5 

[The steps of] Steps 205 and 206 for logging on [205] and authentication [206L 
respectively, as shown in Figure 3 are shown in more detail in Figure 5. A user 201 gains 
access to SpendCap Manager 200, by logging on to the server 203 through a browser [201]. 
Referring now to Figure 5, a preferred method of authentication comprises connecting to the 
server 203 in step 502 using a browser [201]. Log on is preferably accomplished by submitting 
a logon request to the server, along with the user's identity in the form of a username, a 
password associated with the username, and a company name. Company name may be 
provided explicitly by the user or implied by a special URL. The password is received by the 
server in step 504. 

Paragraph on page 10, lines 12-22 

Upon receiving the logon request, the SpendCap server attempts to authenticate the user 
using the attached user name, password [504], and company name. The user is authenticated 
only if the user name exists in the user table of the given company and the given password 
produces a match with the password stored in the user table. In a preferred embodiment, no 
password is actually stored on the server; only a hash value is stored in the user table. The hash 
value is generated in step 506 using a one-way hash function such as MD-5 and the password 
when the user is added to the system. A match of the passwords thus requires generating the 
hash value in step 506 using the given password of step 504 using the same hashing algorithm 
such as MD-5, getting a password hash value from the database in step 508 and comparing the 
hash values in step 510 . A match [510] is produced when the two hash values equal, and thus 
the user is authenticated thereby in step 512 . If the two hash values do not equal, the user is not 
authenticated in step 514. 

Paragraph on page 10, line 23 - page 11, line 6 

Referring now to Figure 4, the application structure 400 of the SpendCap Manager™ 
Module is shown [at 400]. [Each user 402 of the organization is associated with one or more 
departments in the department or organization hierarchy 404 and accesses a unique set of data 
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based on their departmental association. The department] Organization hierarchy 404 is an 
internal tree structure that closely mirrors the organizational structure of the associated 
company or organization. The organization hierarchy 404 is designed to capture the parent- 
child relationship of department objects. For example, the organization hierarchy 404 will 
implement the reporting structure in an organization, so that all departments under a particular 
manager will be children in the hierarchy with the manager's department as their parent. For 
example, in Figure 4, if the manager is in charge of a first department 409, and has a second 
department 410 and a third department 41 1 reporting to the manager, the organizational 
hierarchy 404 will reflect this parent-child relationship as shown in Figure 4. Second 
department 410 and third department 41 1 will be children of parent first department 409 in the 
hierarchy 404. Similarly, fourth department 412, which reports to the manager of department 
411, will be arranged in the hierarchy 404 as a child of parent third department 41 1 , as will be 
child fifth department 413. 

Paragraph on page 11, lines 17-20 

The [department] organization hierarchy 404 shown in Figure 4 helps to enforce the 
access privilege of a user 201. Typically, a user 201 with department access will have access to 
his or her own department 409 for data entry and edit capability, and access to all departments 
or sub-departments 410, 41 1, 412 and 413 below him or her in the hierarchy with viewing 
ability. 

Paragraph on page 11, lines 21-27 

Each department is associated with a specific subset of the global set of spend accounts 
406. The list of users 402, the organization hierarchy 404, the set of spend accounts 406, and 
the mappings among them are all configurable on an on-going basis to match the changing 
needs of the deploying organization. The configuration as well as all data in the system is 
coupled into the stored centrally in a single database 408 via 403, 405, and 407, respectively. 
Individual users can access this central database 408 easily via the Internet 204 through web 
browsers from their own computers , such as described above for user 201 [, as shown in] with 
reference to Figure 2. 
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Paragraph on page 11, line 31 - page 12, line 15 

The SpendCap™ Manager[,] simplifies planning by easily accommodating 
organizational needs and changes. The organizational hierarchy 404, users 402, spend accounts 
406, business drivers, and plan timing elements of a business can be defined and customized by 
users [602] with administrative rights and administrative access via an easy-to-use interface. 
Changes to this information can be done in real time. This capability is especially valuable for 
companies that are growing quickly, and those that undergo frequent merger and acquisition or 
re-organization activities. In addition, this capability provides tremendous flexibility to an 
organization to change or respond to market [conditions] or other changing conditions. In 
addition, although the present example has been described with reference to the head of 
Finance 602 having administrative rights, it should be understood that a plurality of users may 
have such rights. For example, the CEO 601 may have administrative rights. Also, some users 
may be provided with administrative rights for only a portion of the organization hierarchy 404, 
which may be referred to as sub-administrative rights. For example, user Steve 603 in charge 
of R&D [603] may have sub-administrative rights for the portion of the organization 609, 605, 
606 and 610 that reports directly to his department [603], and could have the capability to 
reorganize that portion of the organization hierarchy 404. 

Paragraph on page 13, lines 7-19 

The department object that is created for each user logged on is a node in the structure 
of the department hierarchy 700. The department hierarchy 700 is an internal tree structure that 
closely mirrors the organizational structure of the company 600. It captures the relationship of 
the department objects 701 through 710 and helps to enforce the access privilege of a user. The 
department object 703 assigned to the user Steve 603 when he logs on identifies the position of 
the user Steve 603 in the department hierarchy 700. A user can conduct planning by modifying 
the date contained in the department object. For example, the user Steve 603 in charge of the 
R&D Department [603] can conduct planning by modifying data contained in the 
corresponding department object 703. The user can also view, but not modify, data contained 
in the department objects, which are subsets of the department object. For example, in Figure 
7, the user Steve 603 associated with department 703 could also view, but not modify, data 
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contained in the department objects 709, 705, 706, and [720] 710, which are subsets of the 
department object 703. 

Paragraph on page 13, lines 20-29 

The layout of the department hierarchy 700 is configured during deployment. Therefore 
the relationship between each department object in the department hierarchy 700 is also 
configured at that time. Each department object 703 contains, in addition to the financial data 
in plan objects 7 13 and configuration data 714, a reference 71 1 to its parent department object 
701 and list of references 7 1 2 to its child department objects 709, 705, 706 and 7 1 0. The 
department object 703 shown in Figure 7 is depicted in detail, with it being understood that all 
department objects contain similar details which are not shown in the illustrated example. A 
change to this department hierarchy [layout] 700, such as in the case of a company re- 
organization, will require the re-configuration of the relationship of the affected department 
objects. This will be one of the tasks for an administrato r, such as user Cindy 602. 

Paragraph on page 13, line 30 - page 14, line 7 

When a use r, such as a user Steve 603 A wishes to assign spending capacity to sub- 
departments 609, 605, 606 and 610, the department objects 709, 705, 706 and 710, 
respectively, for the sub-departments 609, 605, 606 and 610 are retrieved from the department 
hierarchy 700, starting from the user's department object 703 and down the list of references 
712 of sub-department objects 709, 705, 706 and 710 contained in the user's department object 
703. Once it is obtained, the user Steve 603 is shown the list of references 712. Any existing 
spending capacity is displayed; the user Steve 603 can change any of the spending capacity and 
save the changes. The changes are saved in the corresponding department object's spending 
capacity plan object 713, which is eventually persisted to a data store 408 such as a relational 
database system. 

Paragraph on page 14, lines 8-19 

Planning for a department's own expenses are accomplished in a similar fashion. The 
user Steve 603 selects which spending category he wants to plan. The system retrieves [the] 
plan objects 713 for the selected category from the user's department object 703. The spend 
account data included in configuration data 714 is shown to the user Steve 603. Any existing 
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spending is included in the display. The user Steve 603 can make modifications to the planned 
spending and save the changes. The changes are reflected in the plan object 713 and eventually 
persisted to the [data store] database 408. This process is repeated for planning each spend 
account [714] in the department object 703. The sum of the total of all the spending accounts 
and the total allocated spending capacity to the sub-departments 609, 605, 606 and 610 must 
not exceed the spending capacity assigned to this department for user Steve 603, as in the 
spending capacity plan in plan objects 713 in the department object 703. If the sum is over the 
spending capacity, the user Steve 603 can submit a request for additional funds, as shown in 
step 212 in Figure 3. 

Paragraph on page 14, lines 20-26 

If the additional funding is granted, the plan can be published as shown in step 210 in 
Figure 3. The step 210 of publishing a plan is accomplished by copying all of the plan objects 
713 in the department object 703 and marking them as public. If a plan has been published 
previously, it will be over- written by the newly published data. The original plan objects 713 
remain in the department object 703, except they are marked as private. The user Steve 603 
refining a plan will only modify the plan objects 713 that [is] are marked with a private 
designation until it is decided to publish the plan. 

Paragraph on page 14, line 27 - page 15, line 1 

A department object 703 is added to the department hierarchy 700 by setting the parent 
department field 71 1 of the department object 703 to an existing department object 701 that 
physically represents the parent department 601 of the department for the user Steve 603. 
Child departments 609 605, 606 and 610 are added by adding department objects 709, 705, 706 
and 710 representing the physical child departments 609, 605, 606 and 610 of the department 
for the user Steve 603 to the list of references 712, which may also be referred to as the child 
department field [712] of the department object 703. 

Paragraph on page 15, lines 2-14 

A department object 703 may contain configuration data 714 such as plan structures of 
the plan objects, spend accounts, headcount types, salary-related rates, salary adjustment rates, 
available currencies, and business drivers. However, such configuration data 714 is not 
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required in every department object. A department object may not physically contain any such 
configuration data. A setting for applicable configuration data 7 14 will be inherited from the 
parent department object 703 by sub-departments 609, 605, 606 and 610 if the configuration 
data 714 is not defined in sub-department objects 709, 705, 706 and 710. If a setting is defined 
in configuration data 714 contained in a particular department object 703, it is specific only to 
the department object 703 and is modifiable by the user Steve 603 associated with the 
department object 703. When a setting is inherited, for example by the department object 705 
from the parent department object 703, the configuration data 714 cannot be modified except 
by the user Steve 603 of the department object 703 from which the setting is inherited. 

Insert the Following Paragraph on page 17 between lines 19 and 29 

For example, in Figure 8, corporate sets the overall spending capacity in step 801 . Then 
in step 802, the spending capacity is distributed to various departments from the top down. The 
distribution in step 802 first occurs in the private planning area called "MYPLAN." Then in 
step 803, the spending capacity is published into a public "SHAREDPLAN." In step 804, the 
spending capacity is distributed further down the organization through the same private/public 
mechanism. In step 805, each department performs a bottom-up expense planning, first in a 
private working area "MYPLAN." Then in step 806, the expense plan is published into a 
public "SHAREDPLAN" As depicted in step 807, if a department requires more funding than 
its allocated spending capacity, the department can generate a request to the department's 
parent department for additional funding. 

Insert the Following Paragraph on page 17 between lines 25 and 26 

For example in Figure 9, a user modifies the private copies of his plans in the private 
planning area and commits changes, as depicted in step 901. Such changes only affect the 
private copies. In step 902, the user attempts to publish his plans. Then in step 903, assuming 
the user's plan is under the spending capacity, the private copies are copied over the public 
copies. 

Paragraph on page 17, line 29 - page 18, line 2 

Certain department expenses are driven off business drivers. Headcount 1004 is a 
business driver and is represented by the headcount plan object 1008 . The headcount plan 
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object 1008 contains the headcount data 1010 having the total headcount of the department, 
including the start/end date, the headcount type which maps to salary or hourly rate. The 
expenses driven off the headcount plan object include the salary and compensation plan and 
other expense plans. 

Paragraph on page 18, lines 12-17 

The major expense plan contain a list of line items (minor accounts) that are associated 
to it such as meal, lodge, car-rental, mileage are to travel expense. Each line item is specified 
as a fixed amount of spending per headcount and/or a percentage of salary per headcount. The 
plan computes the actual expenses of each line item by multiplying the fixed amount with the 
total headcount or multiplying the specified rate , such as the fringe rate 1006 depicted in Figure 
10, with the salary of each headcount. 

Paragraph on page 20, lines 6-12 

Referring to Figure 11, when a user submits a request for additional funds as in step 

1 101 , a request object 1 1 1 1 is created. [A request] Request object 1111 contains a reference to 
the source department object 1120 , destination department object, the current assigned 
spending capacity, and the additional funds requested. The source department object is the 
department object requesting the additional funds. The destination department object is the 
department object approving the request, usually the parent department object. [The] In step 

1102, request object 1111 is sent to the messaging system 1112 in the SpendCap application for 
forwarding to the destination department object 1116 . 

Paragraph on page 20, lines 13-25 

[The messaging] Messaging system 1112 is a mechanism in the SpendCap server for 
sending data among department objects. [A] When request object 1111 is [when] received by 
the messaging system 1112, request object 1111 is appended to an internal queue. Requests in 
the queue are processed in the sequence they are added by a separate thread running in the 
background , such as background thread 1113 . [The] In step 1 103, background thread 1113 
retrieves a request at a time and in step 1104 forwards [it] the request to the destination 
department object 1110 , which adds [it] the request to its own internal queue of requests. The 
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requests will show up when the user of the destination department checks for requests in the 
request page of the SpendCap application. [The] Instep 1105, the user can approve, partially 
approve or reject a request. In any case, in step 1106 a response to the request is submitted 
back to the messaging system 1112 . The response [in] is encapsulated in a response object 
1118 . [A response] Response object 1118 contains a reference to the source department object 
that is the destination department object 1116 in the request object 1111 , a reference to the 
destination department object that is the source department object 1 120 in the [Request] request 
object 1111 , whether the funds [was] were approved or rejected, and the amount approved if 
approved. 

Paragraph on page 20, lines 26-31 

The response object 1118 is deposited into the messaging system's internal queue jn 
step 1106 . The background thread 1113 retrieves the response object 1118 and forwards it to 
the destination department object in step 1108 . The department object matches the response 
object 1118 with the corresponding request object 1111 and updates the status of the request. If 
the request was approved, the approved funding is added to the previously assigned spending 
capacity. The new capacity will be used to enforce the spending when the user attempts to 
publish his plan. 

Paragraph on page 21, line 26 - page 22, line 10 

The TopLine Planner™ module 100 is a web-based application that provides the 
functionality of rapidly refreshing revenue forecasts based upon information available to front- 
line participants in a business organization. Revenue forecasts may be updated based upon 
changes in business conditions, such as price changes by competitors, delayed product 
launches, natural disasters, labor strikes, new discoveries, and other factors. This functionality 
improves financial predictability and increases organizational responsiveness. The TopLine 
Planner™ module 100 provides a unified forecasting method, having distributed access within a 
business organization. The TopLine Planner™ module 100 is preferably linked [107, 108] to 
the SpendCap Manager™ module 102, either directly or preferably through the BizPlan™ 
module 101. Spend capacity plans may be revised in the SpendCap Manager™ module 102 in 
response to changes in revenue forecasts received from TopLine Planner™ module 100 based 
upon P&L calculations performed by the BizPlan™ module 101. Although the illustrated 
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embodiment shows the TopLine Planner™ module 100 as one module in an integrated system 
it, should be appreciated that the TopLine Manager™ module 100 may also function as a stand- 
alone module. 
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MARKED-UP VERSION OF ALL CLAIMS 
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